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ABSTRACT 

A Runway Incursion Prevention System (RIPS) integrated with a Synthetic Vision System concept (SVS) was tested at 
the Reno/Tahoe International Airport (RNO) and Wallops Flight Facility (WAL) in the summer of 2004. RIPS provides 
enhanced surface situational awareness and alerts of runway conflicts in order to prevent runway incidents while also 
improving operational capability. A series of test runs was conducted using a Gulfstream-V (G-V) aircraft as the test 
platform and a NASA test aircraft and a NASA test van as incurring traffic. The purpose of the study, from the RIPS 
perspective, was to evaluate the RIPS airborne incursion detection algorithms and associated alerting and airport surface 
display concepts, focusing on crossing runway incursion scenarios. This paper gives an overview of the RIPS, WAL 
flight test activities, and WAL test results. 
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1. INTRODUCTION 

Runway incursions are a serious aviation safety hazard. According to the Federal Aviation Administration (FAA) 1 , 
during the four year period from fiscal year (FY) 2000 through FY 2003, there were over 262 million aircraft operations 
and 1,475 runway incursions reported at United States towered airports - approximately 5.6 runway incursions for 
every one million operations. This averages out to about one runway incursion per day. During this period seven 
incursions resulted in collisions with one of those resulting in four fatalities. 

The FAA is committed to reducing the number and rate of runway incursions and has begun several initiatives including 
education, training, improved airfield infrastructure (markings, signs, and lighting), and improved procedures. None of 
these initiatives involve technology solutions for the aircraft. 

The National Transportation Safety Board (NTSB) also considers runway incursions to be a serious issue and has 
included runway incursion on its most wanted list of transportation safety improvements since the list began in 1990 2 . 
The NTSB has made a specific recommendation that the FAA require, at all airports with scheduled passenger service, a 
ground movement safety system that provides direct runway incursion warning capability to the flight crew 3 . 

NASA has developed a Runway Incursion Prevention System (RIPS) to improve airport safety by providing 
supplemental surface situational awareness information and guidance cues, and alerts of runway conflicts and route 
deviations directly to the flight crew. RIPS integrates airborne and ground-based technologies, which include advanced 
flight deck displays, incursion detection algorithms, onboard positioning systems, airport surveillance systems, and 
controller-pilot data link communications (CPDLC), with a highly accurate airport geographic database. 

The RIPS concept was evaluated at the Dallas-Fort Worth International airport in October 2000 4 and during a full 
mission simulation study at NASA Langley Research Center in March 2002 5 . The focus of these studies was to 
evaluate the system under single runway incursion situations. Enhancements were made to RIPS based on the results of 
this testing. The system was also modified to enable incursion detection for crossing runway incidents. 

This paper describes the results of a flight test conducted in the summer of 2004 at the RNO and WAL airports, entitled 
the Gulfstream-V Synthetic vision system Integrated Technology Evaluation (GVSITE) flight test. This study, from the 
RIPS perspective, was to evaluate the RIPS airborne incursion detection algorithms and associated alerting and airport 
surface display concepts, focusing on crossing runway incursion scenarios. 



2. SYSTEM DESCRIPTION 


The research system included several test vehicles and technology subsystems that are described below. 

2.1. Test vehicles 

A Gulfstream-owned and operated G-V aircraft was used as the test platform for the RIPS (Figure 1). This G-V has 
been used extensively for flight test research and development. The cabin of the G-V was modified by Gulfstream to 
contain pallets that were outfitted with NASA research equipment. The G-V is a Mach .87, 90,000 pound aircraft, with 
a maximum cruise altitude of 51,000 feet (ft) MSL. 

A NASA Beech Be-200 aircraft was used primarily as the incurring traffic. The Be-200 is an 8,420 pound, 10 
passenger aircraft, with a certified ceiling of 35,000 ft. The aircraft was outfitted with a Universal Access Transceiver 
(UAT) data link system that enabled 
transfer of Automatic Dependent 
Surveillance - Broadcast (ADS-B) 
positioning data with the G-V. 

A NASA van was also used during the 
testing as incurring traffic on selected 
scenarios and for false alert testing, by 
parking up to but behind hold lines. 

The van was also outfitted with a UAT 
data link system for transfer of ADS-B 
positioning data with the G-V. 

2.2. Research displays 

The RIPS flight deck displays were integrated with the SVS flight deck displays resulting in one display system for all 
phases of flight - from enroute to landing to taxi to take-off. The displays were shown to the Evaluation Pilot (EP) 
seated on the left side of the G-V on a Head-up Display (HUD) and on a head-down Primary Flight Display (PFD) and 
multifunction display. The multifunction display could show either a Navigation Display (ND) or an Electronic 
Moving Map (EMM) of the airport surface. The research displays were generated using a 53 by 64 nautical mile hybrid 
terrain database of the WAL area and a WAL airport geographic database developed to RTCA standards 6 . 

Four displays conditions were evaluated during the WAL testing - Baseline with and without FLIR imagery on the 
HUD and Advanced SVS with and without the HUD. 

2.2.1. Baseline display condition 

The Baseline condition (Figure 2) was designed to be representative of currently available displays. Standard stroke 
symbology was shown on the HUD. The head-down displays represented a conventional PFD and ND. The ND was 
co-planar with a map-centered Terrain Awareness Warning System (TAWS) display and a Vertical Situation Display 
(VSD). An airport surface map could be shown in place of the ND, if manually selected by the EP. The Baseline 
surface map showed the airport layout from a top-down view and displayed the locations of the G-V and traffic. 
Runway incursion alerts and synthetic terrain information was not presented on any of the displays for the Baseline 
condition. 

The Baseline Enhanced Vision System (EVS) condition consisted of the same symbology used for the Baseline 
condition with the addition of FLIR imagery on the HUD through the raster channel. 
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Figure 2. Baseline display condition 

2.2.2. Advanced display condition 
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The Advanced SVS display condition (Figure 3) combined the advanced SVS display system with the full functionality 
of the RIPS. The PFD and HUD showed terrain information; conventional flight symbology; advanced pathway, 
approach, rollout, turn-off and taxi guidance; non-conformal taxi turn symbology; airborne and surface traffic; and RIPS 
alerts. The ND showed terrain information in addition to the TAWS warning and caution overlays, VSD, airborne and 
surface traffic, and RIPS alerts. Upon landing and during taxi, the EMM was displayed in place of the ND. The EMM 
showed a perspective track-up view of the airport layout, current G-V and traffic locations, air traffic control (ATC) 
instructions (including the approved taxi route and hold short locations), and RIPS alerts. Previous testing demonstrated 
the ability to data link ATC instructions to the aircraft from ground systems 4,7 . For this testing, the ATC instructions 
were entered into the system from a workstation onboard the G-V. A top down North-up overview of the airport layout 
was also available on the EMM. 

The Advanced SVS-No HUD condition was exactly the same as the Advanced SVS condition except the HUD was not 
utilized. The EPs primary flight reference was strictly head-down. 

2.3. RIPS alerting 


2.3.1. Runway incursion alerting 

RIPS monitored a runway for potential incursions any time the G-V was to enter the runway - during final approach 
and landing, take-off roll, and taxi crossing. Algorithms were running onboard the G-V that monitored for incursions 
based on ownship and traffic state information. If an incursion was detected, alerts were generated and presented to the 
flight crew (audible and graphical). The RIPS algorithms do not provide maneuver guidance for taking evasive action. 
Although not done for this test, these aircraft-generated alerts could be data linked to ATC so the pilots and controllers 
would have the same information. 

Two different incursion detection algorithms were evaluated during this testing. 

The Runway Safety Monitor (RSM) incursion detection 8 algorithm took a generic approach for detecting and generating 
incursion alerts and was not designed for specific scenarios. The RSM monitored traffic that entered a three- 
dimensional virtual protection zone around the runway that was being used by the G-V. Incursion detection was based 
on the operational state of the G-V and traffic, as well as other criteria (including separation and closure rate), to avoid 
false alerts. Identification, position, and altitude data was used to track the traffic in the protection zone. Traffic data 







projections were calculated since updates were not received at consistent intervals. RSM generated Runway Conflict 
Alerts (RCA), which occur when an actual runway incursion is detected and evasive action is required to avoid a 
potential collision. Information provided with each alert included identification of the incurring traffic and separation 
distance to potential conflict. 

The PathProx incursion detection algorithm 9 was designed to handle over 40 specific runway incursion scenarios. 
Alerts were issued based on the states of the G-V and traffic and on conditions including position, speed, and track 
angle. PathProx generated two types of alerts analogous to the Traffic Alert and Collision Avoidance System (TCAS) 
approach. A Runway Traffic Alert (RTA) cautioned the flight crew of a potential incursion or an incursion where the 
conflict did not yet require evasive action. The crew could take evasive action, however, at their discretion. PathProx 
also generated RCAs when immediate evasive action was required. Information provided with each alert included 
identification of the incurring traffic, the runway associated with the traffic, and separation distance between the traffic 
and G-V. 

The alerts were presented to the flight crew both visually on the displays and audibly. An audible enunciation was 
made in the flight deck (“Runway Traffic, Runway Traffic” for a RTA and “Runway Conflict, Runway Conflict” for a 
RCA). The textual forms of these alerts were presented on the HUD, PFD and ND/EMM. On the ND and EMM, the 
traffic symbol representing the incurring vehicle was enlarged, changed color (yellow for RTA and red for RCA) and 
was highlighted by a target designator box. The identification tag was also highlighted. A target designator box also 
highlighted the incurring traffic on the HUD and PFD. In the event the incurring traffic symbol was not shown because 
of the display scale or field-of-view, a symbol was pegged on the edge of the display in the direction of the traffic. The 
distance to the conflict was also shown on all the displays. Figure 4 shows the PFD and EMM during a RCA. 



Figure 4. PFD and EMM during RCA 


2.3.2. Other alerting 

Audible route deviation and crossing hold alerts were also generated by RIPS. Route deviation alerts were generated if 
the G-V left its assigned path during taxi. Crossing hold alerts were generated if the G-V crossed a hold line when not 
cleared to do so by ATC. 

2.4. Position sources 

2.4.1. Ownship position determination 

An AshTech Global Positioning System (GPS) was used to obtain differentially corrected position information onboard 
the G-V. The one second updates of latitude, longitude, and altitude were blended with inertial accelerations to 
compute high rate position updates. 





2.4.2. Traffic position determination 


All of the test vehicles were equipped with ADS-B - a method of broadcasting state information between aircraft and/or 
surface vehicles directly, without the use of ground equipment. The messages contained position, altitude, ground 
speed, track, air/ground status, navigation uncertainty, flight identifier, aircraft ICAO address, and aircraft type. For this 
test, ADS-B messages were broadcast and received by the G-V, Be-200, and test van at a normal rate of twice per 
second using a UAT data link. 


3. FLIGHT TEST OPERATIONS 

The GVSITE flight test was conducted in July and August of 2004 at RNO and WAL. Since GVSITE RNO testing was 
performed during normal airport operations, a subset of RIPS test conditions were conducted due to ATC restrictions in 
place. A full matrix of RIPS testing was completed at WAL and the following data analysis is restricted to the WAL 
test phase. 

During the WAL testing, the EP occupied the left seat of the G-V, where the research displays were located. A safety 
pilot (SP) occupied the unmodified, right seat G-V station. The EP was kept “in the blind” to the greatest extent 
possible during the testing. The RIPS tests were conducted during other SVS technology tests to keep the EP form 
knowing when and which scenarios were forthcoming. Data collection occurred for several different scenarios and test 
conditions as described below. 

3.1. Test scenarios 

Seven incursion scenarios were developed for the WAL testing. Four of these represent the most common types of 
crossing runway incursion situations. All the scenarios were implemented in a NASA simulator prior to flight testing 
in order to determine the proper timing and procedures for all vehicles involved to ensure safety. 

The EP was trained to perform a rejected take-off (RTO) if an 
incursion alert (“Runway Conflict”) was given during take- 
off, perform a go-around if an incursion alert was given while 
airborne, and stop if an incursion alert was given during taxi. 

These instructions were reviewed during pre-test simulation 
training and briefed before each flight. 

3.1.1. Scenario 1 - departure/departure 

Scenario 1 tested the incursion situation in which two aircraft 
are departing simultaneously on crossing runways (Figure 5). 

The scenario began with the G-V in position and hold for 
departure. As soon as the G-V initiated its take-off roll, the 
Be-200 emulated a departure on Runway 35 by accelerating to 
and holding 45 kts to 50 kts for as long as possible. The G-V 
EP was trained to perform an RTO if an incursion alert was 
issued. Otherwise, the SP took control and initiated an RTO 
by 80 kts if using Runway 10 or 60 kts if using Runway 28. 

Both aircraft were required to stop before reaching the 
crossing runway. 

3.1.2. Scenario 2 - departure/arrival 

Scenario 2 tested the case where one aircraft is departing and at the same time another aircraft is landing on an 
intersecting runway. The EP was instructed by the SP to begin the departure when the Be-200, unbeknownst to the EP, 



was 1.5 nm from the threshold of Runway 17. The EP was trained to perform an RTO if an incursion alert was issued. 
Otherwise, the SP took control and performed an RTO by 80 kts if using Runway 10 or 60 kts if using Runway 28, 
stopping before reaching Runway 17. The Be-200 was required to initiate a go-around at 200 ft AGL. 

3.1.3. Scenario 3 - arrival/departure 

Scenario 3 was similar to Scenario 2 except the G-V was arriving and the Be-200 was departing. The Be-200 began a 
“take-off roll” on Runway 35 when the G-V was approximately 1.5 nm from the runway threshold. The Be-200 
accelerated to and held 45 kts to 50 kts for as long as possible, stopping before reaching the crossing runway. The EP 
was trained to initiate a go-around (using the Take-off, Go-Around (TOGA) button) if an incursion alert was issued. 
The EP was then instructed to either continue the go-around or land the aircraft in order to expedite the testing. On test 
runs where alerting was not presented in the flight deck, the SP was required to perform a go-around no lower than 200 
ft AGL (approximately 0.5 nm from the threshold) if the EP did not see the traffic and perform the go-around. 

3.1.4. Scenario 4 - arrival/arrival 

Scenario 4 tested the incursion scenario where two aircraft are arriving simultaneously to crossing runways. The G-V 
was approaching Runway 28 while the Be-200 was approaching Runway 22. The Be-200 made speed adjustments so 
both aircraft would be approximately 2 nm from the threshold at the same time. The EP was trained to initiate a go- 
around when an incursion alert was issued. Otherwise, the SP was required to perform a go-around no lower than 200 ft 
AGL. The Be-200 was required to conduct a go-around at 200 ft AGL. 

3.1.5. Scenario 5 - taxi crossing/departure 

Scenario 5 was designed to evaluate the taxi crossing situation. The G-V was taxiing on Taxiway A toward Runway 10. 
When the G-V was approximately 900 ft from Runway 17 (just crossing Taxiway E), a call was made from the control 
tower for the Be-200 to begin its ‘departure’. This call was made on a radio frequency not monitored by the EP. The 
Be-200 accelerated to and held 50 kts for as long as possible, stopping before Taxiway A. The EP was trained to stop if 
an incursion alert was issued. Otherwise, the SP was required to stop the G-V before reaching Runway 17. 

3.1.6. Scenario 6 - take-off hold/arrival 

Scenario 6 was developed to evaluate the situation where an aircraft is in position and hold while another aircraft is 
approaching the same runway for a landing. As the G-V was in position and hold, the Be-200 approached the runway. 
The EP was instructed to not maneuver upon receiving an incursion alert. The Be-200 was required to conduct a go- 
around no lower than 200 ft AGL. 

3.1.7. Scenario 7 - arrival/take-off hold 

Scenario 7 was similar to Scenario 6 except the G-V was on approach and the Be-200 or NASA test van was in position 
and hold. The EP was trained to initiate a go-around if an incursion alert was issued and to not over-fly the traffic on 
the runway. Otherwise, the SP was required to perform a go-around no lower than 200 ft AGL. 

3.2. Test matrix 

The test matrix consisted of four control variables: evaluation pilot (1-8), scenario (1-7), detection algorithm used to 
drive the displays (RSM, PathProx), and display configuration (Baseline, Baseline EVS, Advanced SVS, Advanced 
SVS - No HUD). The test runs were conducted in both day and night conditions. A total of 81 test runs were 
completed using eight commercial, FA A, and manufacturer pilots as test subjects. 



4. RESULTS 


A summary of quantitative and qualitative results is presented. Distances presented for the G-V are relative to the nose 
of the aircraft. There is a certain amount of variability in the results due to the timing of the scenarios and vehicle 
performance. Although every attempt was made to conduct each test run for each scenario in the same manner, it is 
impossible for the vehicles to begin in the exact same position, use the same approach speeds, use the same acceleration 
rates, stay on the same path, etc. repeatedly. 

4.1. Quantitative results 

During each test run, data were simultaneously collected on the performance of both incursion detection algorithms, 
however, only one method was chosen to drive the flight deck displays when required by the display configuration. Of 
the 81 test runs completed, 51 required alerts be displayed to the EP. During these 51 runs, the RSM was chosen as the 
alert source 84 percent of the time. The decision was made to primarily show the RSM alerting due to a traffic data 
interface issue with PathProx. PathProx was designed under the assumption that the traffic data block would be cleared 
with each new data update, as been done for previous NASA testing. For this test, however, the data was not cleared 
and PathProx would sometimes use erroneous data for the traffic. This issue was not determined until post-test analysis. 

Table 1 summarizes the overall performance of each alerting method. The RSM algorithm alert generation rate was 100 
percent with no missed or false alerts during the course of the testing. In one instance the RSM did not generate an alert 
because the G-V EP saw the traffic on the runway and performed a go-around early before an alert was required. 
PathProx alerted as expected on 41 percent of the runs, while missing alerts on 59 percent of the runs. Thirty-seven of 
the missed alerts were due to the data interface issue discussed above. One of the missed alerts for Scenario 2 was due 
to an issue with the PathProx logic, where the traffic did not transition to the proper state on arrival. The remaining nine 
missed alerts were due to the timing of the scenario. This most often occurred on Scenario 5 (taxi crossing/departure) 
where the SP would call for the EP to stop before the alerting criteria were met. Two of the false alerts were caused by 
a discrepancy between the PathProx alert thresholds and a WAL hold line location. The other five false alerts were 
caused by the data interface issue. 
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80 
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Table 1. Alerting method performance 

4.1.1. Scenario 1 departure/departure results 

Figure 6 shows the distance from the threshold of the G-V when the RTO was initiated and when the PathProx and 
RSM alerts were generated. The figure also shows the location of the Be-200 relative to the G-V when the Be-200 
began accelerating. The Be-200 was on a crossing runway 5593 ft from the threshold of the G-V runway. The RTO 
initiation point was determined by a reduction in the throttle position. 

During the departure/departure crossing runway scenario, the RSM alert generally occurred two to four seconds after 
the Be-200 began accelerating. The EP generally initiated the RTO two seconds after the RSM alert was generated. As 




can be seen in Figure 6, on one of the Advanced SVS - No HUD runs, the RSM did not alert until more than six 
seconds after the Be-200 began accelerating. In this instance, the Be-200 made a gradual, slow acceleration, not 
exceeding 13 kts for five seconds. The RSM alerted one second after the Be-200 accelerated rapidly. 

Figure 6 also shows that PathProx only alerted on two test runs. One of these alerts occurred after the RTO. PathProx 
did not generate alerts on six runs due to the data interface issue described in Section 4.1. 



4.1.2. Scenario 2 departure/arrival results 

Figure 7 shows the distance from the threshold and speed of the G-V when the RTO was initiated and when the 
PathProx and RSM alerts were generated. The Be-200 was approaching a crossing runway 5593 ft from the threshold 
of the G-V runway. The RTO initiation point was determined by a reduction in the throttle position. 

The RSM generated an alert very consistently on six of the departure/arrival crossing runway test runs. For these runs, 
the alert was generated when the G-V was an average distance of 323 ft from the threshold and at an average speed of 
19 kts. On one run the RSM alerted slightly later, when the G-V was 504 ft from the threshold and at 54 kts. This was 
caused by an earlier departure roll by the G-V when the Be-200 was further from the threshold of the crossing runway. 
Overall, the EP initiated the RTO approximately two seconds after the RSM alert was generated. 

PathProx alerted on two test runs, with one of the alerts occurring after the RTO. Three of the missed alerts were 
caused by the data interface issue. One of the missed alerts was due to a PathProx logic issue, where the Be-200 was 
not transitioned to the proper state upon arrival. This logic issue was resolved post-test. The final missed alert was 
caused by a scenario timing issue where the G-V began an early departure roll. 

4.1.3. Scenario 3 arrival/departure results 

Figure 8 shows the distance from the threshold of the G-V when the G-V go-around was initiated and when the 
PathProx and RSM alerts were generated. The go-around initiation point was determined by the moment the TOGA 
button was pressed, if available. Otherwise, an increase in throttle position was used. 

During the arrival/departure crossing runway scenario, RSM alerted an average distance of 1.0 nm from the runway 
threshold and at an average altitude of 296 ft AGL. PathProx alerted on 10 runs with average alerting distances and 
speeds of 0.98 nm and 307 ft AGL, respectively, for the RTA and 0.77 nm and 252 ft AGL, respectively, for the RCA. 
Ten of the 11 missed PathProx alerts were caused by the data interface issue. The other missed alert was due to the 
scenario timing. PathProx also generated five false alerts that were caused by the data interface issue. 


During the Baseline and Baseline EVS configuration - which did not include RIPS alerting in the flight deck - the EP 
saw the departing traffic and initiated a go-around on only five of the 14 (36 percent) runs at an average of 0.73 nm 
from the threshold. On the other nine runs, the SP initiated the go-around. The EP always initiated a go-around when 
an incursion alert was received (average of 0.92 nm from the threshold). This indicates that providing incursion alerting 
to the flight crew results in a greater safety margin and would more reliably prevent the incursion than relying on visual 
acuity, at least for this type of incursion situation. 



4.1.4. Scenario 4 arrival/arrival results 

Figure 9 shows the distance from the threshold and altitude above ground level of the G-V when the go-around was 
initiated and when the PathProx and RSM alerts were generated. The Be-200 was approaching a runway which crossed 
the G-V landing runway only 324 ft from the threshold. The go-around initiation point was determined by the moment 
the TOGA button was pressed, if available. Otherwise, an increase in throttle position was used. 

For the arrival/arrival crossing runway scenario, the RSM generated an alert at an average distance of 1.35 nm from the 
runway threshold and at an average altitude of 516 ft AGL. The EP initiated the go-around 2.5 to 6 seconds after the 
RSM alert was generated. 

On two of the test runs, PathProx generated RTA alerts at approximately the same distance from the threshold, however, 
one of the alerts occurred after the go-around (in response to an RSM alert in the cockpit). The six missed alerts were 
due to the PathProx data interface issue. 

4.1.5. Scenario 5 taxi crossing/departure results 

Timing for this taxi crossing/departure scenario worked well in simulation but was very difficult to achieve in practice. 
On numerous occasions, the SP would make the call for the EP to stop (to ensure that the G-V aircraft did not violate 
the safety rule to remain short of the hold line) before the alerting criteria was met for the incursion detection 
algorithms. The RSM algorithm was modified to generate alerts sooner than initially planned in order to obtain alerts 
for this scenario. The PathProx algorithm was not modified. 



Figure 10 shows the G-V distance from the hold line and ground speed when the RSM alerts were generated and the 
distance from the hold line where the G-V stopped. For this scenario at WAL, the actual hold line was located 75 ft 
from the edge of the runway. A discrepancy was found post-test between the actual hold line location and the hold line 
location in the airport database. The database location for the hold line was 145 ft from the edge of the runway, which 
was the location used by the incursion algorithms, thus resulting in earlier generation of alerts. 

The RSM alert was generated an average distance of 384 ft from the runway hold line. For the runs in which RSM was 
the selected algorithm, the average stopping distance from the hold line was 224 ft. 


PathProx did not generate any alerts for this scenario. The missed alert for one run was due to the PathProx data 
interface issue. All other missed alerts were due to the timing of the scenario. 
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Figure 9. Scenario 4 results 


Hold Line 



RSM 

(EPB) 


Advanced SVS 


Advanced SVS -No HUD 


Figure 10. Scenario 5 results 



4.1.6. Scenario 6 take-off hold/arrival results 


Figure 11 shows the distance from the threshold and altitude of the Be-200 when the PathProx and RSM alerts were 
generated. The G-V was in position and holding for the entire scenario. 

For six of the test runs, the RSM generated an alert when the Be-200 was an average distance of 2.24 nm from the 
runway threshold. The RSM alert was not generated until 1.43 nm from the threshold for the remaining scenario 
because the Be-200 was not lined up with the runway 
until 1.5 nm. 


PathProx generated an RTA when the Be-200 was an 
average distance of 1.15 nm from the threshold and 
an RCA at an average distance of 0.8 nm. The three 
missed alerts were caused by the PathProx data 
interface issue. 

The intent of this scenario was to determine if the 
incursion alerts were provided in a timely manner 
and if the flight crew had sufficient time to react to 
the potential conflict while waiting for take-off 
clearance on the threshold. Four of the five pilot 
responses indicated that the RSM alerting was timely 
and provided sufficient warning. No response was 
made relative to PathProx since RSM was chosen as 
the alerting source for all of these test runs. 

4.1.7. Scenario 7 arrival/take-off hold results 

Unlike the other scenarios conducted, the timing of the arrival/take-off hold scenario was very consistent because the 
traffic (Be-200 or test van) was parked on the runway threshold before the G-V was within 2.5 nm of the threshold. 
Therefore, the performance of the incursion detection algorithms was very consistent. Incursion alerts were not 
required on one of the Baseline EVS runs because the EP saw the traffic when approximately 2.4 nm from the runway 
and conducted an early go-around. RSM alerted on the remaining runs an average distance of 0.95 nm from the runway 
threshold (standard deviation of 0.03 nm). PathProx alerted on 13 runs with average alerting distances of 1.32 nm for 
the RTA (standard deviation of 0.01 nm) and 0.97 nm for the RCA (standard deviation of 0.02 nm). The nine missed 
PathProx alerts were caused by the data interface issue. PathProx also generated one false alert on the test van because 
of a discrepancy between the PathProx alert thresholds and a WAL hold line location. 

Although this scenario was conducted during all four display conditions, conclusions can not be made regarding the go- 
around performance between the Baseline and Advanced SVS display conditions because a complete set of data were 
not available. 

4.2. Qualitative results 

Post-experiment questionnaire results and comments will be incorporated into future evaluations of the system. For 
many of the questions, ratings were given using a Likert-type scale of 1 (completely disagree/low likelihood) to 7 
(completely agree/high likelihood). 

The EPs rated the RIPS as having a higher likelihood of preventing runway incursions than the baseline condition for 
the scenarios evaluated (see Table 2). Five out of six pilots reported that the incursion alerts were provided in a timely 
manner to avoid a conflict and felt that RIPS would significantly enhanced runway incursion safety compared to current 
technology and procedures. All eight pilots stated that the audible enunciation provided the first indication of the 
incursion alert over the graphical displays. Upon receiving the alert, six pilots indicated their immediate reaction would 
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Figure 11. Scenario 6 results 



be to take evasive action while one pilot would confirm the hazard first. The pilots also indicated their situation 
awareness was higher when using the EMM than when using the baseline surface map during airport surface operations 
for own aircraft and traffic position awareness and cleared taxi route awareness (see Table 3). 


Scenario 

RIPS 

Baseline 

1 - departure/departure 

7.0 

2.4 

2 - departure/arrival 

6.8 

1.7 

3 - arrival/departure 

7.0 

2.6 

4 - arrival/arrival 

7.0 

2.4 

5 - taxi crossing/departure 

7.0 

2.4 

6 - take-off hold/ arrival 

7.0 

2.2 

7 - arrival/take-off hold 

7.0 

4.0 


Sufficient awareness of . . . 

EMM 

Baseline 

Ownship position with respect to airport 
layout 

6.7 

5.4 

Ownship position with respect to moving 
traffic 

6.6 

5.2 

Status of taxi and runway surfaces 

6.9 

4.4 

Cleared route 

7.0 

4.0 

Guidance cues to follow cleared route 

6.6 

3.0 


Table 2. Likelihood of incursion prevention Table 3. Situation awareness rating 

A post-run questionnaire was also given where the pilots were asked if the lead time provided by the runway incursion 
alert was acceptable. Ratings were given on a scale of 1 (low) to 7 (high). The ratings for the RSM algorithm for each 
scenario (6.7, 7.0, 6.8, 6.1, 5.4, 6.5, 6.0) indicate that the alerts provided enough warning time for the pilot to avoid the 
collision. PathProx was not evaluated due to insufficient data. 

5. CONCLUSIONS 

A Runway Incursion Prevention System integrated with a Synthetic Vision System was flight tested in the summer of 
2004. The purpose of the study, from the RIPS perspective, was to evaluate incursion detection algorithms and 
associated alerting and airport surface display concepts, focusing on crossing runway incursion situations. The 
quantitative and qualitative data showed overall that RIPS has a higher likelihood of preventing runway incursions than 
the baseline condition for the scenarios evaluated. The incursion alerts were provided in a timely manner to avoid a 
conflict and RIPS would significantly enhance runway incursion safety compared to current technology and procedures. 
The audible enunciation was the most powerful indication of the incursion alert. The pilots also indicated their situation 
awareness for ownship, traffic, and taxi routes was significantly higher when using an advanced electronic moving map 
of the airport surface than present-day technology. 
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